目录开篇5阿里巴巴 DevOps 文化浅谈51.1火遍全球的 DevOps 到底是什么？51.2如何利用 DevOps 进行高效能研发？71.3阿里巴巴是怎样快速落地 DevOps 的？81.4如何享受 DevOps 红利，打造自己的精英交付团队？12敏捷研发篇16业务驱动的精益敏捷实践162.1影响研发效能提升的三大问题 172.2实现精益敏捷研发的四大步骤 18代码管理篇32阿里巴巴自研代码管理平台技术解密323.1阿里巴巴为什么要自研代码管理平台？323.2阿里巴巴代码管理平台的整体策略 333.3云效代码管理平台的核心能力 353.4云效代码管理平台的系统架构 363.5人工智能技术助力敏感信息监测 383.6代码质量饱受好评的 P3C 代码规约检测插件 393.7代码质量缺陷检测技术 PRECFIX 技术揭秘 403.8代码安全敏感信息检测 SecretRadar 413.9智能评审助力开发者提升研发效能 43新一代高效 Git 协同模型详解454.1Git 工作流概述及 AGit-Flow 的优势简介 454.2在阿里巴巴，我们如何使用 AGit-Flow 484.3AGit-Flow 实现原理 494.4AGit-Flow 实现的技术细节 504.5阿里巴巴开源的客户端工具 git-repo 简介 54持续交付篇56企业如何规模化落地 CICD？565.1如何实现持续交付在阿里巴巴的规模化？575.2阿里巴巴实现持续交付规模化落地的两大研发实践 575.3如何进行全局风险管控？595.4规模化落地 CICD 的重要一步 60云原生下的开发测试626.1如何通过 kt-connect 解决本地与集群双向互通问题？636.2KT-Connect 背后的原理 656.3共用测试环境相互干扰问题及常见解决方案 676.4如何使用 kt-virtual-environment 打造项目环境？716.5阿里巴巴使用项目环境的最佳实践 72解决方案篇74云效架构师手把手教你搭建 DevOps 平台747.1背景诉求与推进策略 747.2云效与平台能力 777.3一站式 DevOps 解决方案与详细介绍 797.4三大案例分析 887.5手把手带你完成一个项目 91开篇阿里巴巴 DevOps 文化浅谈本文整理自阿里巴巴资深技术专家陈鑫（花名：神秀）的分享阿里巴巴 DevOps文化浅谈。1.1火遍全球的 DevOps 到底是什么？首先我们简单看一下什么是 DevOps，这个词从何而来。我在这里把 DevOps发展历史分为三个阶段：诞生期、定义期和落地期。DevOps 的“祖师爷”是比利时一名独立 IT 咨询师 Patrick Debois。2007 年，他负责一个大型项目的测试和验证工作，一边和开发对接测试代码，一边和运维对接“发版”。他发现项目组里的开发和运维两个角色的思维方式差异巨大，一边希望“快6阿里巴巴DevOps文化浅谈快快”，一边希望“稳稳稳”，这让他有点崩溃。在 2008 Agile Conference 大会上，Patrick 遇到了 Andrew，两个人一拍即合，开始琢磨如何改变这种 Dev 和 Ops 水火不容的现状。2009 年 10 月，Patrick 通过 Twitter 召集开发工程师和运维工程师在比利时根特市举办了首届“DevOpsDays”大会，开始大规模讨论 Dev 和 Ops 的协作话题。后来为了便于传播“DevOpsDays”被缩写为“DevOps”。在 2009 年以后，DevOps 开始火遍全球。2010 年，The Agile Admin 博客发表文章What is DevOps，详细阐述了 DevOps 的定义，包括一系列价值观、原则、方法、实践以及对应的工具。同样是 2010 年，持续交付的作者 Jez Humble 出席第二届的 DevOpsDays大会，并做了“持续交付”的演讲。这是非常重要的里程碑，可以说持续交付这本书就是 DevOps 的最佳实践，以至于国内搞研发效能的同学人手一本。也正是这本书，加速了业界对 DevOps 的理解以及落地。但我认为业界真正开始大规模落地 DevOps，还是不能离开容器化技术的功劳。“Docker”起到了决定性作用，通过编写 Dockerfile，第一次可以让开发者轻松定义软件运行环境，并且能通过 CI/CD 标准化流程去交付它。不过这么多容器运维起来仍然麻烦，于是 google 在 2014 年开源“k8s”（Kubernetes）；2015 年 CNCF（Cloud Native Computing Foundation 云原生计算基金会）成立，正式将“k8s”作为核心，建立了一个巨大的生态系统。有了“docker”和“k8s”技术上助力，加速了开发和运维角色的融合，于是 DevOps 不再是空中楼阁。回顾完历史，我们对照下自身，通过三个小问题来看看自己的团队是不是已经是“DevOps”了。1.我每次写完代码都可以部署生产环境，不需要别人帮助。2.有很多监控、运维工具可以任我使用，轻松处理线上各种问题和故障。阿里巴巴DevOps文化浅谈阿里巴巴DevOps文化浅谈1.3阿里巴巴是怎样快速落地 DevOps 的？1.3.1阿里巴巴 DevOps 的发展阶段DevOps 的发展永远离不开技术的变革，在 2008 年的时候，淘宝启动了服务化改造的历程，创造了 Dubbo、Apache Alibaba RocketMQ、TDDL（Taobao Distributed Data Layer）等业界知名的中间件。同时淘宝的巨型应用被拆分，变成了下单、会员、优惠等一系列应用，而围绕各个子业务场景更是诞生了成百上千个前台应用。大家可以想象一下当时的开发是怎样的，每周一个固定发布窗口，几百位工程师在临近发布时提交代码、修改 bug、提交测试。在发布日晚上开始按照顺序进行逐个发布，如果发布后出现重大 bug，要么当场 Hotfix（修补程序），要么回滚，宣告发布失败。所有人都被发布日搞的筋疲力尽。第一代自动化发布工具的出现，将发布能力交还给了开发者，同时也迫使开发者去解耦应用依赖，做到独立发布，业务交付速度得到了质的提升。后来大家给它起了一个名字，就是“微服务”。没过两年，随着研发人员越来越多，出现了各种复杂研发规范、各种复杂脚本、各种“挖坑”“踩坑”等情况，让研发工程师苦不堪言。“这一切必须规范起来”，2013 年时我们建立了统一构建部署平台，将阿里巴巴集团从代码变更到线上发布环节完全统一起来，进行严管控。阿里巴巴DevOps文化浅谈阿里巴巴DevOps文化浅谈第二个是流量回放测试技术。这项技术的创新给测试团队带来了很大影响，通过线上流量复制到线下，低成本的解决了测试回归的问题，将传统通过编写用例进行测试，简化为编排数据进行测试。第二层是 Mock 技术的应用，将一个分布式系统问题，转化为单机问题，可以在几秒钟完成上千个用例运行。有了这两个基础技术后，在上层可以发展测试平台，通过算法的手段去识别有效流量，去自动化处理数据，去识别异常流量背后的缺陷。通过这三层面的变革，可以说让阿里巴巴测试效率有了质的变化。第三个是全链路压测技术（对应阿里云上的产品叫 PTS）。双 11 大家之所以能放心剁手，一年比一年顺滑，核心就是这项技术在每次大促前帮助开发者发现风险。发现以后就需要快速的响应，通过 DevOps 工具去解决线上问题。每次压测都是一次练兵，有点类似于军事演习，快速发现问题，快速解决，不断锤炼团队 DevOps能力，也可以这样说阿里巴巴的 DevOps 能力正是一次一次“双 11”给练出来的。1.3.3阿里巴巴 DevOps 两大核心理念 当开发开始定义运维，接手运维的时候。我们管理者会不会有些担忧，比如会不会开发任意操作导致线上故障，随意发布导致稳定性问题等等。阿里巴巴DevOps文化浅谈阿里巴巴DevOps文化浅谈务，一个代码库。以代码为起点，我们又可以串联流水线、环境、测试、资源。最外围是工具链：监控、DB、运维、中间件等等。用应用串联整个工具链，可以让开发人员很好的理解和打通 DevOps 整体过程。不会存在“开发说代码、服务，运维说机器、机房”，这种鸡同鸭讲的情况出现。当工具通过应用打通后，开发人员就可以顺理成章的在平台上定义它的应用，同时也在定义运维规则。比如，规划环境、创建资源、设置发布策略等等，这些都可以由开发人员完成。完成应用和运维定义后，“谁定义就要谁负责”，因此在阿里巴巴，开发人员需要为应用全生命周期负责。通过类似理念和运维工具自动化的推进，“Dev”潜移默化的接手了“Ops”的工作。这时，你会发现原来“DevOps”并没有那么复杂。1.4如何享受 DevOps 红利，打造自己的精英交付团队？通过我们前面提到的阿里巴巴在实践中锤炼的 DevOps 工具，“松管控、强卡点”和“以应用为中心”的 DevOps 理念，阿里巴巴的 DevOps 得以落地，并获取实实在在的效率红利。它消除对个人的依赖，降低团队之间的损耗，降低测试成本提阿里巴巴DevOps文化浅谈阿里巴巴DevOps文化浅谈在传统软件研发过程中，开发者的代码会深度耦合中间件，需要关注服务发现、分库分表、消息处理等多方面。往下也同样需要关注软件部署在哪，需要多少容量，甚至还需要关注操作系统、存储等问题。在云原生时代会很不一样，中间件核心能力会下沉到云基础设施之中，一些常见的限流、降级、鉴权等能力都不需要关心了，数据库、运行环境等都是动态伸缩的，常见的运维问题也不需要关心。只需要开发好代码，通过软件交付平台自动化的发布到云端。软件开发的复杂度其实不会消失，而是换一种方式存在。云原生技术下这种复杂度会下沉到云基础设施层，通过云去屏蔽这种复杂性。那这种复杂性怎么解决，其中一个核心就是用数据去解决。在云原生下我们拥有业界统一的技术标准，比如中间件标准、容器标准等。拥有规范的数据和强大的基础设施，也可以轻松获取到这些数据。有了这些数据，我们就有机会去创造出各种智能工具，去解决我们软件开发的复杂度，或者是通过工具帮助开发者工作，降低这种复杂度。因此在云原生技术下，我们拥有了前所未有的智能的机会和普惠的机会。阿里巴巴DevOps文化浅谈151.4.2云原生时代影响开发者的三大技术体系在云原生时代，我认为会有这三个技术会给开发者带全新的体验。分别是开发态的 CloudIDE、运行态的 Service Mesh、以及运维态的 Serverless 技术。CloudIDE 将开发环境搬到了云上，而且可以和研发平台深度整合，为开发者提供极致的编程体验，再也不用关心我在哪里开发，只要有浏览器，打开就可以编码。中间件在云时代会逐渐融入到 Service Mesh 技术下，服务路由、限流降级等开发者将不再关心。Serverless 技术，让自动扩缩，容量评估变为历史，开发者再也不关心机器在哪。这三项技术将研发全链路云化，并且产生了大量研发数据、服务数据、运行时数据。阿里巴巴在最近几年已经开始投入这些数据的挖掘和研究工作，并且和学界保持着密切的合作关系。敏捷研发篇业务驱动的精益敏捷实践本文整理自洪永潮(舍卫)的直播分享业务驱动的精益敏捷实施。随着 5G、人工智能、IOT 等新技术的迅猛发展，企业的业务都将构架在软件和互联网之上。软件交付能力成为企业的核心竞争力，随着市场竞争的加剧，企业对研发效能的期望越来越高。然而新技术、新业态的不断涌现，又使企业的业务变得越来越复杂，各个团队之间的协作也越来越困难，企业的研发效能呈现降低趋势。“期望”与“现实”之间产生了巨大的“Gap”，正是我们要努力的方向。这就是为什么我们要提升研发效能的根本原因。业务驱动的精益敏捷实践业务驱动的精益敏捷实践精益和敏捷的方案是需要解决上面的三个问题：从局部效率到高效交付，我们需要做到：顺畅高质量交付。从高效交付到持续高效，我们需要做到：持续地顺畅高质量地交付。对于代码设计和质量的长期维护和提高，持续工程能力的积累，持续交付实践的实施等。从高效交付到业务成功，我们需要做到：持续地顺畅高质量交付有效价值。至此，我们定义了问题，也分解了问题，并明确了方向：持续地顺畅高质量地交付有效价值。2.2实现精益敏捷研发的四大步骤精益敏捷研发实践框架业务驱动的精益敏捷实践业务驱动的精益敏捷实践可见，是协作的基础。我们可以通过云效的“看板”实现端到端需求流动过程的可视化，如上图所示在“看板”的最左端是需求池，最右端是“已发布”，其中包含了业务、产品、开发、测试和运维在内的端到端交付过程。打通端到端的业务价值流必须做到：用户价值驱动，即每一个流动单元体现的都是具有用户价值的业务需求；前后职能拉通，即拉通业务、产品、开发、测试等各个职能一起来看整个链路，始于用户问题的提出，终于用户问题的解决。建立端到端的需求流动过程，并利用云效看板实现可视化，这是提升效能的基础。下一步需要明确各阶段的准入准出标准。明确各阶段的准入准出标准，即明确流转规则，是内建质量的重要手段。团队要达成对规则的一致理解并共同守护和持续改进。如上图所示，从阶段“业务讨论”开始到“已发布”都需要有明确的准入规则。举两个具体的例子，一个是从“产品”流入“开发”的规则：开发、测试和产品达成一致，定义明确的验收标准。大需求，需拆分为工作量在两周以内的故事。与关联方（如有）确认相关计划；-识别大的技术风险并定义应对方案。涉及三位及以上开发人员的需求，指定需求负责人，负责协调进度。业务驱动的精益敏捷实践业务驱动的精益敏捷实践什么样的需求才能流转到开发中呢？我们需要为交付团队提供高质量的需求。在产品规划层：需要聚焦端到端的流动效率，并形成价值反馈闭环。而在团队交付层：需要聚焦快速交付业务需求，并保证交付质量。当需求从“产品规划层”流转到“等待开发”这个阶段的时候，需要“指派”给开发团队。需求进入开发团队后，开发同学会把它拆分为“任务”，比如说按照“前后端”会拆分为“前端任务”“后端任务”，针对无线端的任务会拆分为“iOS 任务”“安卓任务”等。只有当所有“任务”开发完成后，满足“提交测试”要求了，才能“提测”。精益敏捷研发第二步：快速高质量交付下面我们接着讲精益敏捷研发第二步，如何快速高质量交付。在软件研发过程中，大多数的时间浪费不是协作上的等待，而是做了很多无价值的需求，以及需求不停地返工。因此发生在软件开发之前的需求澄清工作至关重要。如何做好需求澄清呢？首先，实例化需求。我们的经验是业务、产品、开发和测试一起坐在一起，从场景出发，以用户的操作实例来澄清需求。实例是具体的，其典型形式是：“在什么情况下，做什么操作，会得到什么结果”。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。业务驱动的精益敏捷实践业务驱动的精益敏捷实践 需求进入开发团队的队列（等待开发）后，业务、开发和测试立即通过实例化需求活动澄清需求，用结构化的方式生成需求的验收标准。在开发实现这些需求的同时，团队会将这些需求实例会转化成测试用例，并把部分测试用例自动化，做到功能实现和自动化测试开发同步完成。需求实现完成后，团队会有加工好的测试用例来验收这些需求。甚至可以将部分测试用例提前给到开发人员，让开发提前进行自测。以上形成的循环被称为验收测试驱动开发,这个研发实践在阿里巴巴集团内部和外部都得到大量应用，它重构了开发过程，可有效提升团队的交付质量和效能。当业务需求由产品规划层进入到团队交付层之后，会有两种研发模式来完成需求的开发，持续交付模式和迭代交付模式。我们先来分享一个持续交付模式的实践：限制在制品数量，提高交付速度。如上图在云效的“看板”上，我们可以看到这里的一个“卡片”代表一个业务需求，在“开发中”后面有一个数字（上图中是 3），这代表着并行开发的需求数量。限制并行需求的数量，目的是尽快完成已开始需求，加速需求的流动。更重要的是，“限制并行”能更快暴露问题。因为并行开发的需求有限，当某个需求发生阻塞时，很容易被发现。并行的需求又被称为“在制品”。在云效看板上，所有已经开始，但还没有完成的需求（或其他工作）都是在制品。限制在制品数量的基本原则是：“聚焦完成，暂缓业务驱动的精益敏捷实践业务驱动的精益敏捷实践我们一般用“缺陷趋势图”来度量“交付质量”。如上图所示，图形的横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。小瀑布模式下，交付质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且这一模式通常都导致后期的赶工，埋下交付质量隐患。右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。云效其实已经有了这种“缺陷趋势图”，而且是自动产生的，不需要手动绘制。业务驱动的精益敏捷实践业务驱动的精益敏捷实践映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。用六个字来概括这三个维度就是：又快、又多、又好。有了度量标准之后，我们还要建立效能反馈和改进闭环，才能更好地提升研发效能。通过日常反馈，质量和交付效能的反馈，并定期进行复盘分析，形成流程操作、基础设施、代码与设计、交付及测试守护和人员技能等五个方面的改进行动，然后持续反馈、分析和改进。在实际的操作中，我们发现经过复盘会议后，会产生一些“改进的行动项”，但是这些“Action”的跟进却很困难，往往跟着跟着就跟丢了。在云效当中有一个比较实用的功能，可以将改进的行动项转换成督办任务进行跟进，让行动项妥妥落实，持续促进组织效能提升。精益敏捷研发第四步：规模化实施在讲“规模化实施”之前，我们先来学习一句话。斯蒂芬丹宁（Stephen Denning）曾说“我们需要的是敏捷的规模化，而不是规模化敏捷（方法）”。什么意思呢？我们希望持续地顺畅高质量交付有效价值的能力被规模化，而不是简单地规模化这种方法。业务驱动的精益敏捷实践业务驱动的精益敏捷实践他们有三层看板。第一层是公司级业务运营看板，关注公司战略的落地，如各业务线的投资组合，各业务单元的目标和关键结果，跨业务线的协作和组合创新等。第二层是产品线看板，主要关注产品需求价值流，如端到端需求流动过程，目标反馈闭环等。第三层是交付团队层，主要关注团队快速交付需求，如高质量快速交付，效能反馈闭环等。我们可以看到每条产品线都对应多个不同的交付团队，如果各个产品线之间没有任何“交叉”就比较简单了，操作方式类似前面提到的“单产品线多交付团队”模式。但是也可能出现“跨业务线协作”，这就需要在产品规划层进行拉通。比如在这个例子中“生活业务线产品”的某个功能可能要依赖“中台业务线产品”的某个功能，生活业务线的产品经理就需要将开发需求“指派”到“交付团队 14”，让“交付团队11”和“交付团队 14”协作完成需求的开发。业务驱动的精益敏捷实践31总结前面我们讲到了提升研发效能的方向是要持续地顺畅高质量交付有效价值。介绍了敏捷研发实践的三层框架：目标层、产品规划层、团队交付层。最重要的是精益敏捷研发的四个步骤：打通端到端价值流；快速高质量交付；度量反馈和持续改进；规模化实施。想要落地精益敏捷开发，欢迎体验云效项目协作，立即前往：https:/人以下企业还可申请小微企业扶持计划，免费使用云效 DevOps 一站式套餐。代码管理篇阿里巴巴自研代码管理平台技术解密3.1阿里巴巴为什么要自研代码管理平台？也许你会问：为什么阿里巴巴要重新做一套代码管理平台，继续用 GitLab 版本不是挺好的吗？接下来从我个人的角度在这里尝试进行解答。由于历史原因，在阿里巴巴集团内部代码平台是整个 DevOps 领域中起步相对较晚的一块业务域，相比于发布域、测试域有着多年的积累和沉淀来讲，2017 年时的代码平台可以说是为了满足整体业务需求由几个系统强行拼凑起来的。为了支撑起阿里巴巴整体的业务发展，研发团队要同时维护 6 个系统，分别是负责代码托管的 GitLab、Svn、Gerrit，以及负责上层代码服务的 Phabricator、CodeCenter、ScmCenter。且其中除了 CodeCenter、ScmCenter 之外，其它四个均是在开源系统之上二次封装改造而来的。其中 Gitlab 技术栈是基于 Ruby，Phabricator 基于 PHP，SVN 基于 C，Gerrit 基于 Java,这给我们日常的开发和维护工作增加了很多负担。阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密第三，代码文化，品牌建设：在代码平台建设的同时，要考虑如何对阿里巴巴的代码文化和理念进行正向引导，从而做到以工具和平台作为载体，使代码文化进行有效落地。同时还要进行我们自己产品的品牌建设。第四，拥抱智能，弯道超车：面对竞品我们如何才能真正脱颖而出、打出差异性，答案就是拥抱智能，通过智能化的手段进行弯道超车。基于以上策略，我们开始了自研之路，全新的代码管理平台先是在阿里巴巴集团内部进行落地，进而解决了前文中提到的四个方面的问题。经过充足的准备，我们将这款自研代码管理平台集成到云效中，成为了“云效代码管理平台”，即 Codeup，目前开发者可从云效官网访问并免费使用。“云效代码管理”（Codeup）是一款企业级代码管理平台，提供代码托管、代码评审、代码扫描、质量检测等功能，保护企业代码资产，实现安全、稳定、高效的研发生产。抛开产品设计或团队打造这些方面，我们在技术上究竟是如何做的，这个我会在后面进行详细介绍。阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密综合来看，对于中小企业及大型企业的开发人员，选择成熟的云端代码托管平台，是更安全更省心更经济的选择。3.4云效代码管理平台的系统架构早些年，阿里巴巴集团内部采用的是 AliGitLab 系统架构，虽然在 Gitlab 上进行了分布式的改造，使这套系统的承载能力得到很大的提升。但是 AliGitLab 在架构上仍然属于单层分片架构，因为 Web 服务和 Git 托管这两个核心组件其实是部署在同一台机器上的，耦合十分严重，扩展能力非常差，且整个服务模块都是基于 Ruby 技术栈。这就使整个架构存在两个弊端：一是整个体系基于 Ruby，导致维护、扩展以及人员培养成本都很大；二是 Web 服务和 Git 托管耦合在一起，很多情况下会因为某个节点上代码库读写占用大量资源而对用户在该节点上的页面访问或 API 服务请求造成影响。针对上述问题，我们在云效代码管理平台（Codeup）上实现了全新的架构。通过明确的抽象、分层，将 Codeup 整体划分为三层，即由下至上为存储层、代理层和服务层。同时抽取出 5 个系统核心组件，服务组件间彼此职责单一、分离，上层Service 和 Portal 基于 Java 进行实现，无状态；存储层及代理层组件全部用 Go 语言编写。Codeup-stone 主要负责文件存储及底层 Git 操作的封装，其上抽取一个中阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密除了基础架构，我们在代码智能化、代码规范化等方面也做了大量的投入。基于阿里巴巴集团内部海量的代码数据，在代码安全、代码质量和研发提效等方面的我们都进行了大量探索和创新。这次也是希望借助我们自研的云效代码管理平台（Codeup）将这些优秀的能力开放出去，普惠更多中小企业。接下来，我会针对Codeup 上代表性的功能和工具进行详细介绍。3.5人工智能技术助力敏感信息监测首先，我们来了解一下云效代码管理平台（Codeup）在企业智能安全方面的功能。我们为企业管理者提供了安全风控、审计日志、IP 白名单等把控代码库安全的核心能力。今天主要介绍一下敏感行为监测，我们是如何做的。首先，我们以代码数仓为基础构建了代码图谱，通过对代码库、代码、工程师进行抽象将其转化为实体，并通过实体的标签化构建代码画像、用户画像等。为智能服务提供有力的数据支持，为平台业务提供推理关系查询。在敏感行为检测这个例子中，我们提取出了代码库重要度、文件重要度、代码段重要度、开发人员近期浏览行为、开发人员画像作为安全防护的支撑内容。一旦有重要库、重要文件发生敏感操作，如突然的大量代码库下载、删库、权限变更等行为，我们会立刻给订阅用户发送通知告警，帮助企业管理者感知风险，及时止损。阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密 在 P3C-PMD 组件基础上，基于 IDEA 的 Inspection 机制，以及 Running Inspection By Name 的功能自主实现了 IDEA 插件。Eclipse 插件主要是基于原生已有的 Eclipse PMD 插件进行的规则替换开发。我们通过 IDE 插件的实现，进而解决了本地代码规约检测的问题。综上所述，我们通过不同的插件覆盖了不同研发阶段（如本地编码阶段，自动化全量测试阶段、CodeReview 增量检测阶段）的代码规约检测。通过本地结合线上、全量结合增量的策略，我们实现了一套规则落地多端，进而将阿里巴巴 Java 编码规约通过工具化平台化的手段在阿里内部进行了充分落地。2017 年 10 月份，我们在GitHub 上将 P3C 规则和工具的源码正式对外开源。通过以上努力，我们不仅将 P3C 工具在阿里巴巴集团内部进行了有效落地，同时在集团外也树立了很强的品牌影响力。规约检测工具保证了规约文化的落地及传播，同时规约文化又从效能、人才、稳定性等方面正向推动了整个研发体系的完善。3.7代码质量缺陷检测技术 PRECFIX 技术揭秘由于阿里巴巴集团业务发展的复杂性，上文提到的 P3C、PMD 等传统自动化检测工具不能完全解决阿里巴巴面临的代码质量问题。因为传统工具多是基于规则匹配，不需要了解特定的场景，基于业务场景的 BUG 很难通过这些自动化工具识别出阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密token 等敏感信息通过某些站点被无意识的泄露出去。为了预防这类问题，我们决定在云效代码管理平台（Codeup）提供敏感信息检测的能力。因此调研了业内多款敏感信息检测产品，包括比较知名的 Truffle Hog、Watchtower 等。但是这些工具要么单纯考虑规则匹配，要么采用信息熵技术，召回率或准确率无法满足我们的预期，模型最终效果都不是非常理想。因此，我们在规则匹配和信息熵技术的基础上，结合了多层检测模型和上下文语义检测，打造了一款敏感信息检测工具 SecretRadar，从而使识别效果得到了显著提升。SecretRadar 的实现思路主要分为三个层面，第一层我们采用传统敏感信息识别技术通过丰富的规则集来保证模型基础能力的稳定和可靠，同时确保了模型良好的可扩展性，以此来支持后续用户自定义的能力。但是这种方法非常依赖固化的长度、前缀、变量名等，匹配效果上容易造成漏报。因此针对难以固定规则捕捉的场景，在第二层我们采用了信息熵算法。信息熵可以用来衡量数据集的信息量大小，也就是其不确定程度。所以数据集的信息熵越大，无序程度就越高。通过计算信息熵，可以有效识别随机生成的密文信息，从而提升模型的召回能力，补足基于规则手段的漏报问题。同样信息熵算法也有其局限性，伴随召回的提升是误报率的增加。因此在第三层我们采用了模板聚类的方法，进行了过滤优化。针对信息熵结果集聚合提取常见关键阿里巴巴自研代码管理平台技术解密阿里巴巴自研代码管理平台技术解密可以在第一时间知晓评审的工作量，辅助他合理安排评审时间；第二个场景是对于那些同时要进行多个代码评审的用户，可以帮助他们合理安排评审的优先级。“评审耗时预估”到底是如何实现的呢？首先我们基于阿里巴巴集团内部海量的公开代码数据，收集了几百万次的评审文件浏览数据，提取了包括文本改动、项目历史、行为历史在内的数十种特种，训练了机器学习模型。当开发者提交代码评审之时，我们根据他提交代码的 Diff 内容，自动估算出评审耗时，并伴随代码评审通知一起来告知评审者，帮助他合理安排评审时间。以上能力会在用户授权的情况下，陆续在云效代码管理平台上开放给大家使用。最后，感兴趣的朋友，欢迎体验云效代码管理，领养你的 AI 研发助手。30 人以下企业还可申请小微企业扶持计划，免费使用云效 DevOps 一站式套餐。立即前往：https:/GIT 工作流做了优劣势分析：代码评审模式不同：GitHub 的代码评审称为“pull request”，每个特性改动生成一次代码评审。Gerrit 的代码评审称为“Change”，每个提交生都会生成一个“变更单”，这个变更单就是一次代码评审。工作流类型不同：GitHub 的工作流属于分布式，当开发者需要参与项目的时候，虽然没有“写”的权限，但是可以通过“Fork”的方式创建一个个人仓库（派生仓库），他就可以在这个派生仓库中去创建代码分支，创建 pull request。GitHub 底层采用的是原生的 Git（即 CGit）。Gerrit 的工作流是集中式，所有用户工作在统一管控的集中式仓库中。Gerrit 要求用户在本地克隆仓库中安装一个“commit-msg”钩子，以便在生成的提交中插入唯一的“Change-Id”，向服务器推送要使用特殊的 git push 命令。Gerrit 采用的是 JGit（Java 的 Git 实现）。各自优势：GitHub 简单易用，使用标准 Git 命令即可完成代码贡献；对派生仓拥有完全控制力，不受上游项目影响；可以创建跨项目的开源社区，全球开发者大协同，这也是 GIT 可以形成全球最大的开源社区的原因之一。Gerrit 因为采用集中式的工作流，管理员可以对项目进行严格管控，可以严格控新一代高效Git协同模型详解新一代高效Git协同模型详解4.2在阿里巴巴，我们如何使用 AGit-Flow下面给大家演示一下，在阿里巴巴内部，我们是如何使用 AGit-Flow 工作的。我们首先使用 Git 标准命令将仓库克隆到本地，然后在本地仓库内开发，创建提交。在工作区中执行 git pr 命令，推送本地提交到服务器，服务器端会自动创建一个新的代码评审，例如：pull request#123。团队的代码评审者就可以打开编号“123”的代码评审提交评审意见。开发者根据评审意见，在本地工作区继续开发、新增或修改提交。工作区中再次执行 git pr 命令，推送本地提交到服务器。服务器发现目标分支上已经存在来自同一用户、同一本地分支的 pull request，因此用户此次推送没有创建新的 pull request，而是更新已经存在的 pull request。如果经过多次修改，代码依然不 OK。代码评审者也可以直接发起对评审代码的修改，帮助原开发者更新 pull request。代码评审者可以使用 git download 123 下载编号为 123 的 pull request 到本地仓库，代码修改完毕后，执行 git pr-change 123 命令，将本地修改推送到服务端。服务端接收到代码评审者的特殊 git push 命令，更新之前由开发者创建的 pull request。项目管理者通过点击 pull request 评审界面的合并按钮，将 pull request 合入 master 分支。master 分支被更新，同时关闭 pull request。新一代高效Git协同模型详解新一代高效Git协同模型详解接下来这个“Push”命令就会打入到服务端，服务器端会启动一个进程“git-receive-pack”。（我们对服务器端的前端授权模块做了一些修改，使其能够识别这个特殊的 git push 命令，允许只读用户也能“Push”）如上图所示，“git-receive-pack”我做了星号标记，因为它是一个特殊的“git-receive-pack”。当它发现 push命令的目标是一个特殊的引用后，它不会走 Git 原来内部的工作流，而是走“外部钩子”。通过“外部钩子”完成一些好玩的操作，比如创建代码评审。在今年（2020 年）3 月份，我们已经把这个修改过的 git-core 贡献给了 Git 社区，目前正在评审中，后续 Git 新版本会包含这个新特性：proc-receive。此特性已经历经 15 次迭代，从最初的服务端扩展到集合了服务端扩展和客户端协议升级的完整解决方案。我们将这个技术开源，一方面繁荣了 Git 生态，让更多人能从阿里巴巴的技术中获益；另外一方面，阿里巴巴也得到了收益，我们的代码贡献得到了 Git 客户端的支持，Git 适配了我们新的玩法，让包含阿里巴巴在内的 Git 用户得到了更好的体验。4.4AGit-Flow 实现的技术细节为了解释 AGit-Flow 实现的技术细节，我们先来了解一下 git push 命令原有的实现方式。新一代高效Git协同模型详解新一代高效Git协同模型详解Flow 特殊的命令（group2）。这两组命令经过“pre-receive”钩子检查后，左侧普通的命令（group1）会执行 Git 内置的 execute_commands 函数，生成新的引用，进行分支的创建、更新等。右侧这个特殊的命令会调用一个新的外部钩子“proc-receive”，然后创建一个特殊的代码评审引用，如“refs/pull/123/head”，并且可以用过特殊的 Git 命令将它下载到本地。我们为 Git 贡献的这个新特性，由三部分组成。第一个部分就是“过滤器”，通过在服务端新增新配置变量“receive.procReceiveRefs”来实现。只要定义了这个特殊的配置变量，当客户端使用 git push 命令推送的时候，Git 就会根据配置变量去匹配，当匹配到相应的命令时，这个命令就会走特殊流程。这个配置变量属于多值变量，例如阿里巴巴代码平台的设置是：git config-add receive.procReceiveRefs refs/for git config-add receive.procReceiveRefs refs/drafts git config-add receive.procReceiveRefs refs/for-review这三条配置变量对应 git pr 的三种推送模式，会产生标准的 pull request、草稿模式的 pull request，或者一个代码评审者想推送指定的 pull request。新一代高效Git协同模型详解新一代高效Git协同模型详解可以收到报告信息。例如老版本的 Git 会认为你创建了“refs/for/master”；但是新版本的 Git 懂得扩展协议，可以识别出你创建了特殊的引用，比如知道你创建的不是“refs/for/master”而是“refs/pull/123”这样的引用。4.5阿里巴巴开源的客户端工具 git-repo 简介git-repo 是阿里巴巴开源的一款集中式工作流命令行工具，对原生 Git 命令做了封装，简化了使用 AGit-Flow 等集中式工作流时稍嫌繁琐的 Git 命令。git-repo 是使用 Go 语言开发，运行时除 Git 外不依赖其他软件，所有具有拆包即用的优点。git-repo 具有良好的兼容性，可以支持 AGit-Flow 兼容的代码平台以及 Gerrit。可以跨平台，目前支持 Linux、Mac、windows 系统，其中 Windows 是Beta 版本。除了具备 Android repo 的多仓库管理能力外，还可以对单独的代码仓库进行操作。如何下载安装 git-repo 呢？git-repo 目前已经开源到 Git hub 中，你可以访问https:/页面下载合适的安装包。然后将解压缩后的 git-repo 文件移动到可执行目录中（如 Linux 下的/usr/local/bin 目录），即完成安装。详细的使用方法此处不再赘述，大家可以访问 git-repo 主页了解。新一代高效Git协同模型详解55总结AGit-Flow 是阿里巴巴研发的 Git 集中式协同协议，目前已经在阿里巴巴集团内部生根开花，在外部，通过云效代码管理平台提供支持。AGit-Flow 的核心组件已经开源，将已经成为 Git 的核心组件。为了方便开发者操作，我们开发了 git-repo 命令行工具。git-repo 使用 Go 语言开发，具有拆包即用、跨平台、兼容性好、可扩展等特点。git-repo 已经开源道Git hub 社区大家可以进入产品主页免费下载使用。持续交付篇企业如何规模化落地 CICD？本文整理自阿里巴巴技术专家崔力强（怀虎）的分享企业 CICD 规模化落地。持续交付是随着互联网的迅猛发展逐渐普及的一种研发模式，它具有“快速反馈”“质量内建”“自动化”“开发自运维”等特点。这种研发模式主要包含如上图所示的四个环节，“分支管理”“测试验证”“制品管理”和“发布”。在业界有很多工具支持这些操作，在云效产品矩阵中也有对应的产品提供相应功能。在一个中小型的研发团队（比如 5-10 人），无论你是使用商业软件还是开源的工具，经过一段时间的学习，你都可以把“持续交付”做起来。但是当需要规模化落地之后，就有更多的问题需要考虑，如：如何提高协作效率。新团队如何快速接入。如何进行全局风险的控制。研发流程如何全局更新。企业如何规模化落地CICD？企业如何规模化落地CICD？这里简单介绍一下，感兴趣的同学可以在网上搜索相关文章了解。Aone Flow 使用三种分支类型：主干分支、特性分支、发布分支。主干分支上的代码跟线上版本的代码是一致的，当你要开发一个新的功能时，就会拉取一个特性分支作为开发分支，然后在这个分支上提交代码修改。当你需要发布的时候，需要先将不同的特性分支合并为开发分支再进行发布。发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。这个过程中涉及到大量的“拉分支”“合分支”“打标签”“回滚版本”等等复杂操作，这就需要有一系列自动化工具进行支持。在阿里巴巴内部我们是通过 Aone 平台（即云效的内部版本）提供自动化支持的。第二个实践是以应用为核心的一站式研发体验。“应用”是指一个服务或者微服务，可以直接对应一个代码库。以应用为中心，我们又可以串联流水线、环境管理、构建配置、部署等工具链。可以让开发人员很好的理解和打通整个研发流程，同时也可以帮助一个新团队快速上手。企业如何规模化落地CICD？企业如何规模化落地CICD？5.4规模化落地 CICD 的重要一步通过以上几个措施，就能够在阿里巴巴内部规模化的落地 CICD，当新的研发团队加入时，也不用花费太多的时间去理解这个事情，而是很快上手去操作。但是我们这一套流程也遇到一些问题，这套流程面向 Web 端服务是可以很好去应对的，比如我们只有一个版本的“天猫”“淘宝”，永远是面向最新版去交付的；但是随着阿里云业务的发展，特别是出现了混合云的业务，出现了面向多 Region 和多版本交付的情况，我们这套研发流程就有点捉襟见肘了；因为我们的研发理念是“以应用为中心”，当遇到一些跟应用无关的交付场景时这套研发流程也会显得不合时宜。如何提高阿里巴巴持续交付平台的灵活性呢？我们最早的研发架构如上图左侧所示，底层是研发平台，上面我们做了很多“场景化”的研发组件，同时保留了一定的扩展性，比如“自定义组件”，用户可以把自己的组件接入到我们的流水线里来；也暴露了一部分 API，主要只读接口，其他团队可以在这上面做一些他的场景化。我们认为这种研发架构的灵活性和扩展能力是不足的，（如上图右侧所示）后来我们就把构建、编排、部署、制品这些能力单独拎出来，并开放对应的 API，上层我们再去编纂“场景化”，而且有可能这些“场景”都不是我们开发的，而是使用这个产品的用户自己去开发，重点是我们需要将这种扩展能力暴露出来。我们还会有“自定义步骤”和“自定义组件”，这两个功能已经在云效产品中提供。同时，我们还会开发更多 API、支持更多的源，也可以通过配置 webhook 在流水线的生命周期中（失败、成功、暂停等）通知第三方。企业如何规模化落地CICD？云原生下的开发测试云原生下的开发测试本文整理自阿里巴巴技术专家林帆（金戟）和郑云龙（砧木）的视频分享云原生下的开发测试。在云原生时代下，软件的迭代速度越来越快，对测试的要求也越来越高，很多开发者开始使用 Kubernetes 来管理测试环境。在这个过程中，开发者会遇到很多困难，其中最主要的两个问题是：一、本地环境与 Kubernetes 集群网络不通问题；二、共用测试环境时，相互干扰的问题。在阿里巴巴内部，我们主要通过扁平的内网 IP 和项目环境两个机制来解决以上痛点。扁平的内网 IP 主要是基于 CNI(Conteinre Network Interface)机制改造Kubernetes 的 IP 逻辑实现的，可以使集群中的每个 Pod 分配到的 IP 与本地机器分配到的 IP 处于一个大的网络环境下，这样就可以解决本地环境和集群之间互通的问题。项目环境是基于 RPC、消息中间件的虚拟环境，从表面上看，每个项目环境都是一套独立完整的测试环境，由一系列服务组成集群，而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。这样操作的好处是，第一不会占用大量的开发资源；第二，不会影响公共基础环境的稳定性。云原生下的开发测试云原生下的开发测试直接通过服务的名称进行服务调用，就好像本地的程序运行在 K8S 集群中一样。在KT-Connect 中，我们给这个代理容器取了一个名字“shadow pod”，即“影子”。它就像是本地服务在集群中的影子，通过它来完成本地服务与集群中服务的相互调用。接下来，我们来看第二个场景：其它服务调用我。在联调时，小黑不仅需要调用其它人的服务，同时作为服务的生产者又会被其它服务调用。这时只打通本地到集群的服务是不能满足联调测试需求的，必须同时让集群中的服务也可以访问本地的服务。云原生下的开发测试云原生下的开发测试以“Connect”命令为例，了解一下 KT-Connect 背后的原理。如上图所示，当开发者在本地运行“Connect”命令后，首先会创建一个代理容器（shadow pod），这个代理容器会运行“SSH Server”和“DNS Server”。当代理容器启动成功之后，就可以通过“port-forward”将代理容器的 22 端口转映射到本地，如 2222 端口。此时，本地服务就可以通过本地的 2222 端口建立与集群内部的连接。“Exchange”和与“Connect”命令背后的原理类似，我们也会先创建一个代理容器，并通过“port-forward”将代理容器的端口映射到本地。然后根据Exchange 的目标服务，判断将代理容器的哪一个端口的请求全部转发到本地的特定端口。“Mesh”与“Exchange”的最大的差异在于“Exchange”会将原应用的副本数直接降到 0，会将集群内所有对原应用的流量全部转发到本地。而“Mesh”则是在保持原有应用 Pod 不变的前提下，创建一个新的代理容器并且继承原应用的所有标签，还会增加一个随机的 version 标签。这时我们就可以通过 Istio 规则，精确控制流量。云原生下的开发测试云原生下的开发测试在测试的开发者；一个开发者提交了有 BUG 的代码，所有开发者都可能受影响；一个开发者为了排查问题，单步调试测试环境服务时，所有开发者测试请求会被拦截。如何来解决这个问题呢？以往的思路是准备多套测试环境。虽然这种方式可以暂时缓解开发过程中的相互影响，但是这会带来额外的资源分配和管理问题，特别是当没有那么多并行开发时会产生非常严重的资源浪费。于是出现了一种“改进”方法，企业通过用 helm 或自制工具自动化地快速创建一套环境，用完即删。该方法在一定程度上解决闲置资源回收的问题，但是也没有那么“完美”。在实际操作过程中，环境的创建其实并没有那么“快速”，往往需要等待几分钟甚至几十分钟的时间。而且如果为每个子项目的成员分别拉一套环境，资源浪费依然严重。在多人协同场景下，如何做到测试环境不相互干扰又不产生极大的资源浪费呢？在阿里巴巴内部主要通过“项目环境”的方案解决。“项目环境”的本质是基于路由隔离实现的一个“虚拟环境”。我们通过一个实例来简单了解一下。云原生下的开发测试云原生下的开发测试proj 和公共基础环境中服务 Adev、服务 Bdev 就组成了一个新的的“项目环境”（图中红色部分）。这时“小黑”的同事也加入了项目，他在本地启动了一个服务 A，如果他没有对这个服务打“环境标”的话，他会默认使用“公共基础环境”进行测试。这时小黑在他自己的“项目环境”中的任何调试都不会影响到小黑的同事，反之亦然。后来小黑的同事和小黑加入了同一个子项目，他们之间需要“联调”。这时，小黑的同事只要给他本地的服务打上一个和小黑的“项目环境”相同的环境标即可，如上图红色部分。总结一下前面介绍的概念：“隔离域”是由路由规则形成的虚拟边界；每个“环境云原生下的开发测试云原生下的开发测试kt-virtual-environment 实现的基本原理是：观察并持续监听环境中的所有服务和开发资源，动态生成 Service Mesh 控制面规则，实现核心隔离逻辑。当前kt-virtual-environment 仅支持基于 Istio 的规则，未来会增加基于其它 控制面的Service Mesh 规则的实现。6.5阿里巴巴使用项目环境的最佳实践“项目环境”在阿里巴巴内部已近发展多年，下面我将一些优秀的实践分享给大家。理论上，“环境标”的层级可以无限多，但是我们的经验是最好不要超过三级。因为三层的“环境标”基本上可以满足 95%以上的研发场景。云原生下的开发测试73以三层环境标实现的项目环境举例。第一层一般只有一个环境标，比如 dev，这是对应默认隔离域（公共环境）使用的环境标，这样做会让整个路由规则比较简单，大家不用猜测“路由兜底”最后会“兜”到哪里去。这个顶级的 dev 环境标对应的测试环境是不需要开发者自己去部署的，一般是通过“流水线”等自动化工具部署的稳定版本。对于某个子项目，我们可以基于顶级环境标建立一个二级环境标，如dev.proj1，这样会形成这个子项目的隔离域（项目环境）。在这个隔离域中，只需要开发者自己部署需要改动的服务实例即可，其它不需要改动的服务实例可以复用公共环境中实例。有的时候，某位开发者可能要对某服务进行比较大的改动或者他不希望这个服务被其它同事访问到，他可以基于“项目环境”再创建一个“个人环境”。在这个个人环境中，他既可以调用子项目中的服务，也可以调试本地开发的新的服务版本，并且不会影响到其他开发者。以上，是我们比较推荐的项目环境的用法。总结：云原生测试环境工具箱共包含两款独立的工具：kt-connect 和 kt-virtu-al-environment。kt-connect 是一款本地工具，主要是帮助开发者打通本地和集群网络，实现本地加入隔离域。kt-virtual-environment 是一种基于 Service Mesh的微服务环境复用工具，通过观察并持续监听环境中的所有服务和开发资源，动态生成 Service Mesh 控制面规则，实现核心隔离逻辑。只需要一次性部署，开发者不会频繁使用到。目前两款工具已经开源，大家可以进入 Github 社区进行下载使用。解决方案篇云效架构师手把手教你搭建 DevOps 平台本文整理自阿里巴巴云效研发解决方案架构师红英的分享云效架构师手把手教你搭建 DevOps 平台；由阿里云开发者社区志愿者徐海轩整理。7.1背景诉求与推进策略方案背景一站式 DevOps 解决方案致力于顺畅高质量地交付有效价值：顺畅指交付过程中不存在反复和阻碍，快速完成；高质量表示交付过程中产生曲线较少，交付后线上故障较少；有效价值指做出的需求真正是用户想要的。当今世界是个节奏加速的世界，大鱼吃小鱼，快鱼吃慢鱼，每家公司都多少与软件业务相关联，软件交付和创新已经成为企业核心竞争力。随着业务发展和市场竞争的加剧，对软件研发效能的要求不断提高。同时但随着 ioT 和新零售等业务场景出线和相关协作复杂度的提升，研发效能反而有降低的趋势。互联网时代下企业的 DevOps 诉求 互联网时代下，企业的 DevOps 诉求主要分为以下六个维度：云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台研发资产沉淀：将个人能力沉淀为组织能力，需求上的沟通与协作，代码质量，测试资产，发布与构建的质量和相关线上故障等都是公司软件研发资产，进行需要沉淀。Devops 落地推进策略 这一策略主要分为四个维度阐述：平台化：企业建设项目管理、研发、测试、发布一站式平台，各个孤岛打通进行相应协作，将所有数据沉淀到线上并基于数据持续改进。标准化：做到需求变更规范标准化：例如准入准出需求。研发人员代码规范标准化：例如代码规约，定义方法等。编译打包规范标准化：要求一次相同代码在所有环境下打包一致，不能出现这次 A 包下次 B 包的问题。自动化部署流程规范标准化：如果没有相应红线质量规范，手工去做相应发布的触发很容易引发线上故障，产生事故。自动化：DevOps 推进过程中希望一切都由机器操作，从而展现自动化速度快的优势并降低出错率。自动化方面从编译打包自动化，代码扫描自动化，环境管理自动化，部署自动化和测试自动化五个维度实现 DevOps 落地。可视化：可视化的目的是希望一切信息对所有人透明：例如研发效能，质量，自动化数据度量等。再按照可视化的数据进行相应改进。云效架构师手把手教你搭建DevOps平台 开发-测试-发布-运维-运营”端到端的协同服务和研发工具，支持公共云、专有云和混合云多种部署形态，通过人工智能、自动化技术的应用助力开发者提升研发效能，持续快速交付有效价值。可能有人会问一站式解决方案能不能只用其中的一部分，答案是肯定的，云效支持单独使用协作，code 和发布的流水线等相关模块。云效存在先进的管理理念，智能的技术应用，全方面的安全保障，高效的过程交付，高效的团队协作以及灵活开放的产品策略，众多方面我们将在下文中逐一进行后续介绍。云效平台能力云效具备六大模块构成平台能力：78云效架构师手把手教你搭建DevOps平台前两个模块是项目协作，包括需求管理模块和质量管理模块。需求管理又分为精益模式和迭代模式，质量管理则体现在测试用例库的管理。针对每个版本发布测试计划，将测试用例拷入进行测试，对产生缺陷做缺陷跟踪，待版本迭代上线后做质量分析。第三大模块是代码托管平台，主要进行代码托管，代码提交以及分支管理，研发人员提交代码后能够自动触发扫描，并在通过后进行代码评审和分支合并。第四模块是流水线，开发写完代码触发流水线做版本构建 构建完做版本正式环境部署 流水线过程中会构建出相应包，该包触发第五个模块制品仓库，它同时支持公库与私库，私库内具备二方包和构建出来的产物，并将产物存储到 OSS 上或镜像仓库内。第六个模块是知识库管理，涵盖产生需求过程中的需求文档，研发做详细概要设计产生技术文档，会议讨论纪要，将这些记录用于改进总结和沉淀。因此，云效是集成阿里巴巴最佳实践、一站式软件研发全生命周期管理的协作平台。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台研发从写代码到提交缩短到 1 小时发布前置时长；每天至少有 1 个可发布版本达成持续集成；每周至少能发布 1 次保证高持续发布频率。下面是模块实现详细介绍。项目协同-看板模式 其一是端到端的价值交付过程，包含需求池，已选择，分析中，待发布和已发布五个环节，是从需求收集到需求发布的一个整体的端到端交付过程。过程中涉及的产品经理，开发，测试，运维人员等各个角色的前后职能都得以拉通，并将需求的进度展示在同一看板上。并保证了需求中每个卡片都是用户价值驱动的，同一个需求可以拆分前后端，安卓与 iOS 等子功能，形成左右模块的对齐。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台测试用例部分是针对产品来说的，测试人员用测试用例管理沉淀用例内容，用例可以被重复使用，减少测试人员重复工作量，提高企业测试用例编写规范。测试计划则针对每个发布版本，与特定内容对应，例如功能测试和回归测试等，测试人员在具体项目内用测试计划做测试工作的执行过程管理，帮助测试人员对测试过程进行记录和协同，可以全面提升测试效率和软件交付质量。发现缺陷后则进行缺陷管理，测试人员通过自定义的工作流来管理缺陷提交-修复-验证关闭流程，强制流转规则保证信息的完整性；通过缺陷类型、严重程度、优先级、标签、等字段定义缺陷属性，进行细分管理，并分配给对应的开发人员进行修复。通过测试管理的用例，计划，缺陷三个管理方向，能够串联测试人员的测试计划，提高相应测试效率和软件交付质量。代码安全 代码安全的构筑分为三层，最底层的数据安全，指代码存储在 code 平台的数据具备足够的安全性，做到自动快照和分布式存储，并置于最高等级机房内，保证数据云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台研发人员和代码打交道，主要对象是远程仓库代码，接到研发任务后即可创建特性分支，再在远端 clonepull 到本地完成代码，并在本地提交后再 push 远端，每次push 都会自动触发代码扫描，扫描通过后才能通过合并请求和触发代码评审，并在过后再自动合并到代码 master 分支。代码评审分三个维度：轻 CR：只要提交和并请求通过即可，没有评审过程；重CR：为保证任务质量需要人员介入，由团队资深同学评审；自动化辅助 CR：用于提高效率，只要代码扫描没有问题就自动合并代码。流水线方案 流水线分为持续集成和持续发布两个部分。持续集成是由开发者提交代码，或合并其开发分支到集成分支，触发发布流水线的运行。软件自动完成代码扫描、软件构建、部著到测试环境，完成集成测试。如果成功完成验证，自动合并到待发布分支。目标是每天至少存在一个待发布版本。持续发布则是软件达到可发布状态后，通知发布负责人，发布到生产环境。同时准备回滚预案。最终可发布版本的发布部署由发布窗口及人工审核来决定。目标是一周至少一次。整个流水线方案过程中都可以用钉钉消息进行沟通，并反馈发布结果给研发人员。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台K8S 部署 前面也与通用步骤一致，区别只是编译出构建的产物是镜像，并将其追踪到镜像仓库。部署的时候会触发 kubernetes，从镜像仓库中拉取 docker 再部署到生产环境中。部署策略支持滚动升级，蓝色部署，分批第一批暂停和分批每批暂停四种。机器上支持阿里云 K8S 和原生自建 K8s，环境类似都是项目，SIT，预发和生产四个，只是区分于部署的内容非包，而是镜像。反馈改进机制 云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台7.4三大案例分析案例 1星汉博纳在星汉博纳上，云效实现了一套持续的改进过程，做到了过程有追溯，资产有沉淀，改进有依据，使得原本散落的各个企业平台能在端到端中实现打通。首先是需求收集和产品管理，由运营人员收集需求池进行任务排期和项目管理，并使需求透明化，让提需求的人能看到进展，研发和测试人员能看到排期，需求排期后转入团队交付看板进行迭代，版本与缺陷方面的管理，再交由开发人员做产品的代码编码和测试用例实现，并接下来将代码提交进代码库，做 code review 和测试管理。图像中曾经只作为规划功能的两条虚线：代码 commit 关联工作项与缺陷，发现状态自动同步工作项和缺陷目前都已经全部实现，代码通过后继承触发应用集成发布的流水线。测试服务方面支持测试用例管理和根据用例计划缺陷自动化接入 SaaS 服务，环境上也做了日常环境，预发环境和生产环境的划分。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台案例 3商米科技 这个案例中，被替代的方案分为需求流和代码流，需求流的迭代模式存在时间盒，迭代计划批量进出，整个过程位于黑盒，只有实际测试发布后才能发现问题，导致发布经常延期，不仅质量不高还需要大量人员的加班加点。代码流则受限于环境准备，本地开发从 master 拉取分支写代码会显著延长调试时间，每天只能进行两次 push 到特性分支，同时人工触发联调。每个版本都要等环境，手工维护拉取分支编译触发修改脚本要一天以上，再去做相应的预发布还需要1-3 天测试，提测后合并发布要两周一次，特别冗长。而如今，在云效进行 DevOps 改进后，商米提出了 1-1-1 的三个愿景目标：每个组每周至少发布一次，每天都有可发布的 build，每次发布前置时长 1 小时。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台现在开始开始介绍产品的实操演示，图中页面就是云效 2020 新版产品页面，重点介绍代码平台，项目管理以及流水线。利用左边 dock 登录个人工作台，打开左上角可以看到产品，包括知识库，文档托管平台，流水线，代码管理，制品仓库，测试管理（管理测试计划和测试用例），工作台（可以理解为项目管理平台），企业成员和企业管理后台是企业成员级的设置。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台重点介绍敏捷开发场景 点击进入一个敏捷开发项目空间 可以看到需求任务迭代等目录选项 首先从日常工作开始，首先会基于一项需求开始生命的一个开端，提前做了一些 demo 数据，以笔记应用作为需求，左上角可以看到针对笔记应用的需求分类，例如笔记本，笔记操作，权限，模板等。有日常需求即可按加号新建，在需求界面里可以设置需求的起止时间，关联迭云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台此时右上方点击前往【迭代】规划需求按钮，可以看到提前建了一个 Sprint002的需求迭代，并已经关联了一部分需求在内，此时即可进行需求迭代开发工作。如果第一次去新规划迭代，则可以在迭代窗口右上角点击加号，以创建新迭代，可以自建名称，选择交付时间和负责人 刚创建好的页面是空的，此时点击规划迭代即可开始规划。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台接下来介绍测试方面的内容点开 dock 能看到测试管理模块，主要是管理用例库的，点击右上角即可创建笔记任务的用例库空间，可以编写测试用例，定义不同场景分组进行规划，因为这是企业级的用例，所以进行管理后可以直接在相关项目中对这些用例库进行调用。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台这里可以针对缺陷进行分类，比如围绕需求的不同进行分组，便于直观的进行查看。还有一些其它的服务能力，例如日程能力，这里可以添加一些项目的周会或其他会议。设置日程时间，进行提前提醒，创建好的日程会被划入日历。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台统计右上角有新建项目报表的功能，它支持多种报表模式，例如你比较关心一些效能分析方面的指标，就可以启动交付周期报表，需求控制图或者需求累计流图。缺陷统计中，同样可以根据场景和诉求新建各种报表，例如缺陷的变化趋势，累计趋势以及缺陷按迭代分布等，便于去分析问题和进行下一阶段的计划改进。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台在知识库中可以管理产品需求，会议纪要等日常文档和企业知识沉淀。代码管理详述这里就是代码管理平台的页面，对代码管理的介绍分两部分，一个是企业级代码平台设置，另一个是用户级的代码平台设置内容。我们第一时间即可感受到平台的安全性，这一安全性在事前防范，事中应对和事后追溯方面都有相应的体现。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台安全层面的第二部分是安全通知，对代码库的所有操作都是留痕的，比如公开原本私有的代码库，删库等等，这些过程都可以根据需求选择进行站内或邮箱通知。安全通知记录可以用右上角的导出键导出，一次最多一万条，方便企业用于分析和排查。回到代码管理首页，还有一个重点内容是审计日志。第一个是库管理日志，这个日志中可以看到基于库曾经进行的操作，例如添加或删除成员，目录操作，以及成员权限的更新都能一览无余。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台首先介绍设置菜单内的一些能力，点击右上角设置，点选集成与服务进入集成服务界面，这里介绍和代码质量高度相关的能力，例如 Java 开发规约和敏感信息监测等，这一部分企业可以根据自身需求决定开启或关闭。很多企业都非常关注质量话题，它是效能提升的重要保障，通常情况下，代码质量更受测试人员关注，但研发过程中提前重视这一过程将非常有利于软件交付质量的提升。这时就可以前置部分检查，例如开启 java 规范扫描或敏感信息检测等，对此可以设定一些触发方式，如代码提交触发和合并请求触发，作为提交的卡点要求。接下来介绍分支设置，分支设置中主要想介绍代码评审能力，主要是用新建保护分支的方式进行归纳，例如可以新建 master 保护分支，并调节推送规则，规定那种角色的人员在完成怎样的动作后才能 push 到分支上，达到提交的标准。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台快速基于此分支提交文件后，能够看到刚刚创建的分支正在运行，进行 Java 开发规约以及敏感信息的扫描，点击即可看到详细的扫描内容，扫描多少文件，是否出现问题。这一步可以用来进行问题分析，确认无误后即可进行合并请求的新建。进入合并请求界面，可以看见设置的刚刚的卡点要求需要通过，对应着正在进行的自动化检查和代码的人工评审。此时可在界面右侧添加评审人，此时相关评审人就云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台的流水线中，并可以修改定位至全部流水线，这里可以进行一些个人权限的控制，例如谁仅能查看流水线，谁可以进行编辑。这里介绍一个主机部署的场景，这是一个持续集成的流水线，分为测试，构建，环境部署，测试验证，在通过后合并到发布分支，并转进持续发布的流水线。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台最后快速演示一下新建流水线的过程，回到流水线主界面，点击右上角新建流水线,这里可以看到许多设置好的模板，初次使用时可以在左侧根据开发语言进行选择，例如根据 Java 主机部署场景快速创建。流水线的出发源可以是业界所有的主流代码仓库，例如 Codeup，Github 等，也可以绑定 Jenkins 账号进行任务对接。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台机类型有阿里云的 ECS 和非阿里云的公网自有主机。这里可以根据应用环境的不同进行主机组的划分，例如测试环境和日常环境下。后续会加入一个轻应用的概念，通过应用的不同进行主机资源和环境的管理。主机组选择后即可进行其它配置，例如部署脚本的输入，暂停方式的选择，是每批暂停或者仅首批暂停，可以根据企业要求灵活进行配置。云效架构师手把手教你搭建DevOps平台云效架构师手把手教你搭建DevOps平台最后，感兴趣的朋友，欢迎体验云效新一代 DevOps 平台，建设自己的研发流程，提升研发效能。30 人以下企业还可申请小微企业扶持计划，免费使用云效 DevOps 一站式套餐立即体验：https:/